Method for converting an object code into a program code

ABSTRACT

A method for converting an object code (OC 1 ) for a source hardware (M 1 ) into an equivalent program code (PC 2 ) that comprises a program part (PT 2 ) and a data part (DT 2 ), whereby a code transformer (CT) analyzes each command of the object code (OC 1 ) for the source hardware (M) and generates at least one corresponding entry in the program part (PT 2 ) of the program code (PC 2 ) from it is developed in that at least one data part (DT 1 ) of the object code (OC 1 ) for the source hardware (M 1 ) and at most the complete object code (OC 1 ) for the source hardware (M 1 ) is accepted into the data part (DT 2 ) of the program code (PC 2 ). Such a method is flexible and offers high efficiency both in the conversion as well as in the running of the converted program code (PC 2 ).

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention is directed to a method for converting an object code fora source hardware into an equivalent program code according to a methodfor converting object cod for a source hardware into equivalentexecutable program code for a target hardware where the program codecomprises a program part and a program part. In particular, theinvention is directed to a method for converting an object code suitablefor an earlier processor generation into a program code that is runnableon current hardware platforms.

2. Description of the Related Art

The increasing demands made on the performance capability of computersystems often require a switch to new computer generations, for examplefrom CISC to RISC computers. Since, however, the programs existing forprior computer generations represent great economic value and can benecessary for the smooth execution of company-critical procedures, it isdesirable or even indispensable to continue using the existing softwarebase.

Manually rewriting of the programs onto the target hardware is verytime-consuming and costly. Different techniques of automatictransformation have therefore been proposed.

When the existing programs or parts thereof are present in the sourcecode of a standardized language, they can usually be converted onto thenew target hardware by simple re-compiling. An automatic conversion islikewise possible for application programs that are present as assemblersource code for the source hardware. Such a method, which, however, isnot provided for the conversion of an object code, is disclosed inGerman Patent Application DE 196 17 842.

Often, however, user programs are only present in the form of an objectcode runnable on the source hardware. This is particularly the case forapplications that have been modified over the course of years at theobject code level. The original source code for such programs—if it isstill available—is usually unusable since it does not contain thechanges that have been made.

It is known to dynamically transform object code for a source hardwareon the target hardware in the fashion of a command interpreter. Such anemulation of the source hardware, however, requires a great deal ofcomputing time which cancel out the higher performance capability of thenew hardware. Programs that usually run significantly faster on thetarget hardware can be produced with methods for static programtransformation.

U.S. Pat. No. 5,313,614 discloses a method for static conversion ofobject code between computer systems having different hardwarearchitectures. In the converted program, a complete image of the addressspace of the source machine is contained in the RAM of the targetmachine. This image, for example, contains an image repetition store andaddresses for input/output registers. Memory accesses of the convertedprogram occur in the corresponding addresses of the image. Accesses ontoaddresses that trigger a side affect in the source hardware are therebyintercepted and suitably converted.

This method is therefore provided for the conversion of object code thatdirectly accesses the hardware of the source machine, but is relativelycomplicated precisely because of the support of hardware-relatedfunctions. This is true both with respect to the computing expenditurerequired for the conversion as well as the implementation of theconverted program.

The article, “Binary Translation” by R. L. Sites et al. in theperiodical Communications of the Association for Computing Machinery,Vol. 36, No. 2, February 1993, pages 69-81, shows a method for binarycode conversion in which existing VAX and MIPS programs are convertedinto binary code for RISC computers. This method comprises converting anobject code for a source hardware into an equivalent program code thatcomprises a program part and a data part, in which a code transformeranalyzes each command of the object code for the source hardware andgenerates at least one corresponding entry from it into the program partof the program code, by which a part of the object code for the sourcehardware is accepted into the data part of the program code. It alsoincorporates all of the original object code (data and program part)into the generated binary code. In this method, machine code isgenerated for alpha-AXP processors in order to obtain an optimallydirect imaging of the structures of the source hardware onto structuresof the target hardware.

Converting existing CISC object code into optimized RISC code is knownfrom the article, “Migrating a CISC Computer Family onto RISC via ObjectCode Translation” by K. Andrews et al. in ACM SIGPLAN Notices, Volume27, No. 9, September 1992, pages 213-222.

The article, “A Methodology for Decompilation” by C. Cifuentes et al. inXIX Conferencia Latinoamericana de Informatica, Buenos Aires, Argentina,August 1993, pages 257-266, first mentions early work in the field ofdecompiling object code into high-level language source code, in whichthe authors proposed their own procedure for this decompiling. In thismethod, a high-level language program code is generated via a pluralityof intermediate steps that comprises optimally far-reaching high-levellanguage constructs. Correspondingly, memory accesses of the originalobject code are converted into global and local variables of thehigh-language program code.

SUMMARY OF THE INVENTION

The invention, has the object of offering a method for converting of anobject code into an equivalent program code that is flexible andefficient in view of the actual conversion of the code and in view ofrunning the converted program code. In particular, the method should besuitable for efficient conversion of object code for user programs,i.e., of non-privileged object code.

This object is inventively achieved by a method for converting an objectcode for a source hardware into an equivalent program code that may berun on a target hardware and that comprises a program part and a datapart. This method comprises the steps of analyzing, by a codetransformer, each command of the object code for the source hardware,generating a corresponding entry from the command of the object code inthe program part of the program code, accepting a part of the objectcode for the source hardware into the data part of the program code, inwhich the part of the object code for the source hardware accepted intothe data part of the program code corresponds to a data part of theobject code for the source hardware, generating a source code of ahigh-level programming language as a program part of the program code,and partially retaining access into the data structures of the objectcode for the source hardware that are contained in the data part of theprogram code in the source code.

The invention proceeds from the basic idea of converting the object codeinto an equivalent program code that operates on the data structures ofthe original code. This avoids the difficult or even unsolvabletransformation of data structures of the object code into datastructures of another programming language.

The invention makes it possible to transport user programs that, forexample, are present in the object code for the system 390 onto otherhardware platforms, for example, onto RISC hardware, in a simple way.Since at least one data part of the original object code is acceptedinto the generated program code, this data part is directly availablefor memory accesses onto the data structures of the original objectcode. On the other hand, it is at most the complete object code that isaccepted into the program code. An administration of the completeaddress space of the source hardware—which can be several times greaterthan the object code and must be monitored for memory accesses havingpaging effects—is therefore not required.

In the vocabulary employed here, “program code” does not necessarilymean a single data file. On the contrary, the program code can be formedof several parts from which a runnable program is then generated bycompiler and/or assembler and/or linking events. Likewise, a program,data or link part does not necessarily mean an interconnected memoryarea; rather, each of these parts can be formed from a plurality ofsections and/or memory areas and/or routines.

Inventively, accesses onto the data structures of the object code forthe source hardware are at least partially, but preferably completelyretained; a complete retention facilitates the conversion procedure.However, it can also be provided that specific classes of datastructures be recognized and these—when possible—be converted in anespecially efficient way independently of the original object code.

Preferably, the data part of the converted program code is exclusivelyformed by the object code for the source hardware or parts thereof andexhibits no further component parts, such as low-level hardwareaddresses.

Inventively, a source code of a higher programming language is generatedas a program part of the converted program code. A higher programminglanguage means a language that comprises constructs such as floatingdecimal point functions and/or function calls and/or named variablesand/or a type system. In particular, the C language or a relatedprogramming language is used as the high-level programming language forthe program part of the converted program code. The use of such ahardware-independent programming language enhances the flexibility ofthe method because C-compilers are available for practically allhardware architectures of possible target machines.

In preferred embodiments in which a higher programming language isemployed for the program part of the converted program code, theregisters of the source hardware are modeled by variables of the higherprogramming language. Furthermore, procedure and/or function calls canbe utilized for simpler and structured simulation of complex commands ofthe source hardware. These possibilities established by using a higherprogramming language facilitate the conversion procedure and make itpossible that a comparatively assessable program code can be produced.This code can be more easily further-modified by hand as warranted.

Branches in the original object code are preferably implemented via abranch table in the transformed program code. This, is required when thehigher programming language employed exhibits only limited branchpossibilities.

The method is preferably provided for the conversion of non-privilegedobject code, since such object code comprises few or no hardware-relatedcommands, which facilitates the conversion procedure.

An analysis of the object code in view of its program and data parts ispreferably undertaken. Sections of the original object code that aredependably recognized as program parts need not be accepted into thedata part of the generated program code. For sections that aredependably recognized as data parts, no command sequences need to begenerated in the program part of the generated program code. Sectionsthat cannot be dependably identified must be incorporated into the datapart of the program code and must additionally be inserted as commandsequences into the program part of the program code.

In preferred embodiments, the generated program code contains a linkpart in order to enable mutual calls between converted program codeand/or original object code and/or further program modules.

BRIEF DESCRIPTION OF THE DRAWINGS

An exemplary preferred embodiment in the invention, as well as a numberof modifications of the embodiment are described in greater detail belowwith reference to the drawings.

FIG. 1 is a schematic illustration for explaining the basic principle ofthe inventive method;

FIG. 2 is a flowchart of the conversion of an object code for a sourcehardware into an object code for a target hardware;

FIG. 3 is a schematic illustration of the program part generated by theconversion;

FIG. 4 is a schematic illustration of call relationships between twoobject code modules; and

FIG. 5 is an illustration according to FIG. 4, whereby one of the objectcode modules has been converted into a program code.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

In FIG. 1, an object code OC1 runnable on a source hardware M1 isconverted with a code transformer CT into a program code PC2 that isprovided for a target hardware M2. The object code OC1 comprises a datapart DT1 that is distributed into a plurality of individual sections inthe object code OC1.

The program code PC2 is composed of a plurality of parts that are storedin separate data files. One program part PT2 contains source code in theprogramming language C. A data part DT2 contains a complete copy of thedata part DT1 of the object code OC1 for the source hardware M1. A linkpart VT2 enables mutual calls between the program code PC2 and externalroutines. Further, a library BIB with assembler routines is provided inthe program code PC2 for the execution of complex or hardware-relatedfunctions (for example, arithmetic functions, particularly floatingdecimal point arithmetic ). The program code PC2 is not directlyexecutable on the target hardware M2 but must first be compiled (orassembled) and linked.

FIG. 2 shows the procedure of converting the object code OC1 for thesource hardware M1 into an object code OC2 for the target hardware M2.In step 10, the original object code OC1 is read in. The steps forgenerating the program code PC2 are combined in a block 12 in FIG. 2.The read-in-therefor; object code OC1 is first subjected to a codeanalysis (14). The objective of the code analysis is to resolve theobject code OC1 into code and data parts; this, however, is not alwayspossible to do in an unambiguous manner.

In the code analysis in step 14, the possible program execution in theobject code OC1 is tracked proceeding from a known start address. Toachieve this, the object code OC1 is interpreted command-by-commandstarting with the start address, and the commands that are reached areidentified as such. Unconditional branches are implemented. Eachconditional branch, by contrast, opens up two paths that are to betraversed. First, all conditions are assumed to be met. When the programcode or a code part that has already been run is reached (the latter isthe case for loop branch-backs), the address level is switched back tothe conditioned branch executed first, and the alternative path(condition not met) is traversed.

In this way, all conditioned branches are gradually worked off in themanner of a back tracking algorithm, resulting in all possible paths inthe object code OC1 being run and marked as commands. In a last step ofthe code analysis 14, the remaining regions of the object code OC1 thathave not been reached are searched for valid operation codes. Regionsthat were not reached in the traversal but contain an accumulation ofvalid command codes, are interpreted as not being unambiguouslyclassifiable because they could be potentially reachable in the programrun by branches having a calculated branch destination.

As a result of the code analysis 14, parts of the object code OC1 areclassified as data, parts are classified as code and parts areclassified as not reliably classifiable. The sections that are notreliably classifiable are converted both into C-code and are alsoaccepted into the data part DT2. The data part DT2 can thereby possiblybe more extensive than necessary, and the C-code in the program part PT2can contain “dead” code. The correctness of the converted program codePC2, however, remains assured.

In alternative embodiments, other methods and other heuristics can beutilized for determining the data encode sections of the object codeOC1. In another alternative embodiment, the code analysis 14 is foregoneand the complete object code OC1 is accepted in the data part DT2 of theprogram code PC2 and is converted as C-code in the program part PT2. Inan alternative procedure, the result of the code analysis 14 can beutilized only for determining the code part or the data part DT1 of theobject code OC1. The complete object code OC1 is then employed as theother respectively part.

The data part DT1 of the object code OC1 identified in the code analysis14 and that can be composed of a plurality of sections is output into adata file as a data part DT2 in step 16.

In step 18, the program part PT2 and the link part VT2 of the programcode PC2 are generated from the object code OC1 and the informationacquired in the code analysis 14. Details of this procedure aredescribed below. The parts PT2 and VT2 of the program code PC2 areoutput into separate data files in step 20.

In step 22, the program part PC2 is compiled with a known C-compiler,and the assembler routines in the link part VT2 are converted intoobject code with an assembler known in and of itself In step 24, themodules generated in the steps 16 and 22 as well as the globallyprescribed library BIB specific for the target hardware M2 are bound.The resulting object code OC2 runnable on the target hardware M2 isoutput in step 26.

The program part PT2 generated in the code generation in step 18 (FIG.2) comprises the structure illustrated in FIG. 3. Stated more precisely,the program part PT2 is composed of a declaration part DECL, of a codepart CODE and of a branch table TAB. The case of an independentlyexecutable program part PT2 is considered first. Such a program part PT2is fashioned as the “main” module of the language C.

The declaration part DECL contains definitions of data structures thatsimulate the non-privileged hardware structures of the source machineM1. Because the conversion method is only provided for non-privilegedcommands, only a few types of processor registers need to be simulated(for example, general registers and condition code registers). For thesake of simplicity, the data structures for processor registers aredefined as a union set of all data types that the registers can contain.This is expressed in the following, exemplary type definition in thelanguage C:

typedef union genregs {

unsigned long int u;

long int s;

unsigned char *p;

} REGS390;

Corresponding declarations are placed into the declaration part DECL forthe individual registers, for example:

#define MAX390REGS 20

REG390 r[MAX390REGS];

In order to generate the code part CODE, corresponding commands of thelanguage C are generated for each command of the object code OC1. Whichsections of the object code OC1 are to be interpreted as commands isdefined from the result of the code analysis 14. In the exemplaryembodiment described here, all sections of the object code OC1 aretranslated that have not been dependably identified as data of the datapart DT1.

A group of C-commands is generated in the code part CODE for eachassembler command in the object code OC1, namely, first, an unambiguouslabel (branch destination mark), then a conversion of the assemblercommand and, finally, commands for simulating side effects of theassembler command. The generated C-commands reflect the transformationsthat the converted assembler command executes on the registers and inthe memory of the source hardware M1.

The label generated for each assembler command is derived from theaddress of the converted assembler command. Furthermore, this address isalso defined as a symbolic designation in a hexadecimal notation. Thelabel and the symbolic designation are employed in the branchdestination table TAB (which will be explained below). The followingentries are therefore first generated in the code part CODE for acommand that is located in the object code OC1 at the hexadecimaladdress 201A:

1 _(—)201A;

#define L_(—)201A 8218

the assembler command is now converted, in that its effect on theregisters and in the memory of the source hardware M1 is simulated byC-commands. For example, the object code for the register subtractioncommand

SR R3, R2

is converted into the C-notation

r[3].s−=r[2].s.

In order to simulate side affects of the assembler commands in theobject code OC1, a few further elements of the source hardware M1 mustbe simulated in addition to the general registers, such as a conditioncode register that automatically changes dependent on the result ofspecific commands and is interrogated for conditioned branches. For theregister subtraction command described here by way of example, thefollowing C-code is therefore additionally generated for setting thecondition code register r[CC]:r[CC]  .s = (  (r[3]  .sr[2]  .s)  ?  0   : (  (r[3]  .s < r[2]  .s)?  1 : 2)  ).

In the exemplary embodiment described here, C-commands that suitablysimulate the status of the condition code register and other specialregisters of the source hardware M1 are always generated in theconversion of a command of the object code OC1. For the non-privilegedprograms exclusively under consideration here, however, only a fewhardware structures of the source hardware MI need to be modeled.

In order to enhance the implementation speed of the converted program,optimizations are provided in alternative embodiments. For example, fora plurality of sequentially executed commands before a conditionedbranch command, the conditioned code has to be generated only for thelast command before the branch instruction, since all earlier conditioncodes are thereby overwritten.

In the conversion of the object code OC1, accesses into memory areas ofthe source hardware M1 are imaged onto corresponding accesses in thedata part DT2 of the program code PC2. Thus, for example, the objectcode for the register load instruction

L R2,ENDAREA

is converted into the C-code

r[3].u=*(unsigned long int *) (r[10].u+226);

where R10 serves as base register and 226 is the offset of the symbolicaddress ENDAREA in decimal notation. The condition code register in theassembler language described here by way of example is not modified forload instructions.

Hardware-related commands in the object code OC1, which cannot becompletely imaged by C-commands, are converted in that a call of anassembler routine from the library BIB is incorporated into the codepart CODE. The library BIB is permanently prescribed for the targethardware M2 and contains entries for those commands of the sourcehardware M1 that are to be implemented directly by machine code of thetarget hardware M2. Among the non-privileged commands to be convertedhere, however, only a few require a call of the assembler library BIB(for example, synchronization commands for the memory access).

For conversion of branch instructions in the object code OC1, themodule-global branch table TAB is employed in the generated program partPT2. The branch table TAB contains a branch instruction (“switch”) ofthe language C that, for each instruction address of the object codeOC1, comprises an entry (“case”) with the branch destination address ofthis instruction. The labels defined in the code part CODE are enteredinto the branch table TAB as branch destinations, whereas the symbolicdesignations determined with #define serve for better readability of thebranch destination addresses. An exemplary excerpt from a branch tableTAB is shown below:

BranchTab:

switch (branch destination) {

case L_(—)2018: {goto 1_(—)2018:}

case L_(—)201A: {goto 1_(—)201A:}

case L_(—)201E: {goto 1_(—)201E:}

In order to implement a branch in the converted C-code, a branchdestination address is calculated and a branch is made to the branchtable TAB. For example, an unconditioned branch instruction to asymbolic mark START0 with the decimal offset 14 is converted into theC-code

branch destination=r[10].u+14;

goto BranchTAb;

where R10 contains a base address. For conditional branches, acorresponding if/then command is generated in the code part CODE, the“if” part comprising, for example, an interrogation of the conditionedcode register.

In alternative embodiments, information are determined in the codeanalysis (step 14 in FIG. 2) regarding which commands of the originalobject code OC1 are possible branch destinations. In this case, only thepossible branch destinations need be identified with a label in theprogram part PT2, resulting in the control flow becoming substantiallymore efficient. The possibilities of optimization by the C-compiler areexploited better since each group of C-commands generated from a commandin the original object code OC1 no longer has to be isolated with alabel.

In further alternative embodiments, another high-level programminglanguage or an assembly language serves as the language for thegenerated program part PT2. When, in this latter case, the assemblerlanguage of the source hardware M1 is used, a disassembler functionalityis achieved by the method. The assembler source code generated in thisway can be manually modified or can be converted with other methods.

The conversion method discussed above shows how, a completely boundobject code can be completely converted into a C-program. The C-programhas the form shown in FIG. 3, with a “main” function that potentiallycalls further functions serving for classification. In the more complex,general case, the object code OC1 to be converted, however, only forms apart of a larger program system that should cooperate, with the othermodules. The other modules can likewise be converted by the methoddisclosed here. However, for example, they can also be dynamicallyinterpreted on the target hardware M2.

In order to enable a mutual program call between the modules convertedby the method disclosed here and potentially other modules, assemblerroutines are used that are inserted into the link part VT2 by the codetransformer CT in the code generation (step 18 in FIG. 2). Furthermore,the generated program part PT2 no longer comprises a “main” module butonly a normal C-function. For a call from the outside, the images of thehardware registers of the source machine M1 as well as auxiliaryinformation about the desired point of entry are handed over, as shallbe described in greater detail below.

Given the program system for the source hardware M1 shown in FIG. 4, twoobject code program modules OC and OC1 are provided. The module OC1 hasa point of entry E1 that is branched to from the module OC by a call 28.After processing a suitable function, a branch-back 30 take place fromthe module OC1 to a point X1 of the module OC.

Of the two modules OC and OC1, only the module OC1 is to be convertedinto an equivalent program code PC2, as shown in FIG. 5. In order toenable the mutual calls between the module OC and the program code PC2,the code transformer CT generates a plurality of assembler routines inthe link VT2.

When a function of the program code PC2 is to be called from the objectcode OC, the current status of the hardware register at the point intime of the call must be handed over to the C-program part PT2 in theform of a parameter. Furthermore, the address of the entry point E1 mustbe handed over a parameter in order to be able to branch to this pointof entry E1 in the program part PT2.

Stated more precisely, the call 28 of FIG. 4 is subdivided in threesteps shown in FIG. 5. In the first step 28 a, the point of entry E1from the object code module OC is called in the assembler code of thelink part VT2. This assembler code implements a call 28 b of the (only)C-function contained in the program part PT2 with the current values ofthe hardware registers and the address of the point of entry E1 asparameters. The branch 28 c is implemented with a branch table accordingto the transmitted point of entry address.

When, in contrast, a routine in the object code OC is to be called fromthe program part PT2, as is the case in FIG. 4 given the branch back 30,the current register status, as maintained in the program part PT2 inC-variables, must be handed over to the called assembler program. Thiscall takes place in two steps 30 a and 30 b shown in FIG. 5.

In step 30 a, an assembler routine EXIT is called in the link part VT2.The current values of the register variables and the destination addressin the object code OC are handed over to the routine EXIT as parameters.The assembler routine EXIT now loads the hardware registers of thetarget machine M2 with the current values and, in step 30 b, branches tothe desired destination address, the address X1 here.

When the program part PT2 comprises a plurality of entry points, acorresponding plurality of entry points are provided in the link partVT2. For a branch in the program code PC2, the destination address inthe program part PT2 is set only by the assembler routine in the linkpart VT2 that is branched to. In contrast to this, the destinationaddress is handed over as parameter for a branch from the program partPT2, so that a single routine EXIT suffices.

Mutual calls between an arbitrary number of modules are possibleaccording to the method described here.

In this exemplary embodiment, mutual calls also take place betweenprogram parts that have both been converted according to the inventivemethod, taking place via the assembler routines of the link part VT2. Inalternative embodiments, this situation is recognized for optimizationand is converted into a direct C-function call.

What is claimed is:
 1. A method for converting an object code for asource hardware into an equivalent program code compatible with a targethardware and that comprises a program part and a data part, comprisingthe steps of: analyzing, by a code transformer, each command of saidobject code for said source hardware; generating a corresponding entryfrom said command of said object code in said program part of said theprogram code; accepting a part of said object code for said sourcehardware into said data part of said program code wherein the part ofsaid object code for said source hardware accepted into the data part ofsaid program code corresponds to a data part of said object code forsaid source hardware; generating a source code of a high-levelprogramming language as a program part of said program code; partiallyretaining access into said data structures of said object code for saidsource hardware that are contained in said data part of said programcode in said source code; and converting registers of said sourcehardware as variables of said high-level programming language.
 2. Amethod according to claim 1, further comprising the step of forming saiddata part of said converted program code exclusively by parts of saidobject code for said source hardware.
 3. A method according to claim 1,further comprising the step of generating a source code of theC-language as a program part of said converted program code.
 4. A methodaccording to claim 3, further comprising the step of convertingpredetermined commands of said object code for said source hardware as afunction or procedure calls of said high-level programming language. 5.A method according to claim 1, further comprising the step of sequencingbranch commands of said object code for said source hardware utilizing abranch table of said program code.
 6. A method according to claim 1further comprising the step of analyzing said object code for saidsource hardware in order to identify a data part of said object code forsaid source hardware.
 7. A method according claim 1, further comprisingthe step of enabling branches into said generated program code or out ofsaid generated program code via a link part of said generated programcode.
 8. A method according to claim 1, further comprising the step ofconverting said generated program code by compilers or assemblers orlinking into an object code executable on said target hardware.
 9. Amethod for converting an object code for a source hardware into anequivalent program code compatible with a target hardware and thatcomprises a program part and a data part, comprising the steps of:analyzing, by a code transformer, each command of said object code forsaid source hardware; generating a corresponding entry from said commandof said object code in said program part of said the program code;accepting a part of said object code for said source hardware into saiddata part of said program code wherein the part of said object code forsaid source hardware accepted into the data part of said program codecorresponds to a data part of said object code for said source hardware;generating a source code of a high-level programming language as aprogram part of said program code; partially retaining access into saiddata structures of said object code for said source hardware that arecontained in said data part of said program code in said source code;wherein said method is utilized for converting non-privileged objectcode.
 10. A method according to claim 9, further comprising the step ofconverting registers of said source hardware as variables of saidhigh-level programming language.